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(54) Method and apparatus for detecting input directed to a thread in a multi-threaded process 



(57) A method and apparatus are disclosed for han- 
dling an input event directed to a thread within a process 
operating in a multi-threaded system. A process is 
alerted that an input event effecting one of its active 
connection threads has been received. An input polling 
thread in the process is enabled and is used, in conjunc- 
tion with other thread-specific data, to determine which 
of the threads in the process has an event directed to it. 
That thread is then triggered to handle the input event. 
The active connection thread receiving the input event 



is assigned a light weight process to execute only after 
it is determined that the thread requires it to process the 
input event. The input polling thread for a process 
detects input events for its process and causes the 
appropriate connection thread in the process to be 
assigned a light weight process when the connection 
thread needs it to execute. This greatly reduces the 
number of light weight processes assigned to threads in 
a multi-threaded operating system. 
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Description 

BACKGROUND OF THE INVENTION 

1. FIELD OF THE INVENTION 

[0001] The present invention relates generally to the 
field of computer software and client/server applica- 
tions. In particular, it relates to directing data from cli- 
ents to appropriate processes and threads in a multi- 
threaded operating system. 

2. DISCUSSION OF RELATED ART 

[0002] As network and distributed computing environ- 
ments expand, the processing demands on operating 
systems running and supporting these environments 
increase. As networks grow, the number of users and 
the amount of data expand while expectations regarding 
response time and general operating system features 
increase with time. In some cases, while resources 
available in an operating system, especially those run- 
ning in a distributed computing environment, may have 
been adequate for the number of users or volume of 
data initially contemplated for the network, these 
resources become increasingly valuable as the 
demands on the network grow. The volume of individual 
user requests grows while the operating system's pool 
of resources remains constant. 
[0003] Two particular kinds of resources used by an 
operating system are generic processes and thread- 
execution enablers referred to in some operating sys- 
tems as light weight processes. One type of generic 
process has its own pool of resources, such as memory, 
file descriptors, and stack routines. Existing within, this 
type of process is, in most cases, a variety of threads, a 
thread being a piece of executable computer code des- 
ignated to accomplish a specific and generally narrow 
task. 

[0004] The types of threads contained in a process 
vary according to the function and overall requirements 
of the process and operating system. Behind each proc- 
ess and thread is a light weight process which enables 
the process or thread to execute by making system calls 
and performing input and output operations on behalf of 
the process or thread. For example, a light weight proc- 
ess allows a piece of code to make calls to the operating 
system. Thus, a thread or process effectively can not 
operate without being assigned a light weight process 
by the operating system. Typically, a light weight proc- 
ess is assigned to a thread when the thread makes a 
system call. However, an operating system normally 
has a limited number of light weight processes it can 
assign and this pool can be depleted if the number of 
processes and threads rapidly increases. 
[0005] In some cases, a process, or threads within a 
process, may be waiting on an external event to occur or 
for input from an external source. For the process or 



thread to be "listening" for some type of external signal 
or data, it requires that it have a light weight process 
behind it. If the number of threads waiting for input or the 
number of processes running keeps growing, the more 

5 light weight processes the operating system will need to 
assign. When all the light weight processes have been 
assigned and a process P1 is ready to execute (and, 
thus, needs a light weight process), some operating 
systems perform context switching with another proc- 

10 ess, for example, P2. Context switching is a compara- 
tively resource-intensive operation where the operating 
system to accommodate the needs of P1, saves the 
context of P2, restores the context of P1 and assigns to 
it the now available light weight process from P2. The 

15 system then allows P1 to run and, when it is complete 
or remains idle, restores the context of P2 and assigns 
the light weight process. This type of context switching 
[i.e. saving and restoring processes' contexts) for entire 
processes normally requires significant processing time 

20 and system resources and, thus, is undesirable. The 
concept of having threads within a process stemmed 
from the desire to reduce process context switching. 
[0006] It is also undesirable to have each thread, 
especially in high-volume multi-threaded operating sys- 

25 terns, assigned its own exclusive light weight process. 
This situation is particularly inefficient and wasteful 
given that, in many situations, threads are idle or in 
some type of input wait state most of the time, where 
they are not actively processing data or executing. In a 

30 high-volume network with thousands of users, the 
number of light weight processes can begin to run low. 
This problem is also true in smaller networks where the 
number of light weight processes available in the oper- 
ating system may have been initially set to be relatively 

35 small. Even though starting and stopping a light weight 
process does not require significant overhead, it is very 
desirable for the operating system to always have them 
available when needed. Regardless of the size of the 
computing environment, threads can easily proliferate 

40 and consume valuable system resources, such as light 
weight processes. 

[0007] Therefore, it would be desirable to have a 
mechanism that would decrease the number of light 
weight processes assigned to threads, particularly in 

45 the context where the threads require the light weight 
process solely to detect an external signal directed to 
that thread. It would be desirable for the operating sys- 
tem to assign a light weight process to a thread that 
requires the light weight process for execution only, 

so thereby making more efficient use of the system's light 
weight processes and fostering overall savings in sys- 
tem resources. 

SUMMARY OF THE INVENTION 

55 

[0008] To achieve the foregoing, and in accordance 
with the purpose of the present invention, methods, 
apparatus, and computer readable medium for handling 
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an input event directed to a thread within a process 
operating in a multi-threaded system are disclosed. In 
one aspect of the present invention, a method is pro- 
vided in which a process is alerted that an input event 
effecting one of its active connection threads has been 
received. A special thread referred to as an input polling 
thread in the process is enabled and is used, in conjunc- 
tion with other thread-specific data, to determine which 
of the threads in the process has an event directed to it. 
That thread is then triggered to handle the input event. 
[0009] In one embodiment an execution enabler, such 
as a light weight process, is assigned to the input polling 
thread and then run thereby enabling the input polling 
thread. In yet another embodiment, a list of threads 
maintained by a process is checked wherein each 
thread can be identified by a file descriptor and has an 
associated thread identifier, a thread wait variable, and 
an error return code. The state of a thread wait variable 
is changed when an input event directed to a thread 
associated with the thread wait variable is received. 
[001 0] In another aspect of the invention, a method of 
invoking a thread in a process when an input event is 
received and using a reduced number of light weight 
processes is disclosed. An input event directed at an 
active connection thread is received and a polling 
thread is used to determine which active connection 
thread the input event is directed to. A single light weight 
process is used by the appropriate active connection 
thread to handle the input event only such that the light 
weight process is assigned to the thread only after it is 
determined that the input event is directed to that 
thread. In one embodiment a conditional wait thread is 
run to monitor changes made to the active connection 
threads receiving an input event to ensure execution of 
those selected active connection threads. 
[001 1] In another aspect of the invention, a computer 
system configured to receive input from users where the 
input is directed to a specific thread contained in a proc- 
ess is disclosed. An input polling thread detects input 
events directed to active connection threads in the proc- 
ess and routes the event to the selected thread. Only 
the input polling thread requires a light weight process 
for detecting the input event thereby reducing the need 
for light weight processes used by the active connection 
threads, which would previously be needed for detect- 
ing input events. An input wait table associated with the 
process is structured for monitoring and storing informa- 
tion on the active connection threads where the infor- 
mation indicates which active connection threads are 
executing an input event. The input polling thread polls 
the input wait table to determine which active connec- 
tion thread an input event is directed to thereby reducing 
the need for the active connection threads in the proc- 
ess to individually monitor input events. 
[001 2] In one embodiment of the present invention, a 
conditional wait thread monitors the input wait table to 
determine which selected active connection thread has 
had a state change. This ensures that the active con- 



nection thread with a state change is assigned a light 
weight process. 

BRIEF DESCRIPTION OF THE DRAWINGS 

5 

[001 3] The invention, together with further advantages 
thereof may best be understood by reference of he fol- 
lowing description taken in conjunction with the accom- 
panying drawings in which: 

10 

Figure 1 is a block diagram showing various com- 
ponents of a message access configuration in 
accordance with one embodiment of the present 
invention. 

15 Figure 2 is an illustration of an input wait table asso- 
ciated with a process in accordance with one 
embodiment of the present invention. 
Figure 3 is a flowchart showing a method of execut- 
ing a connection thread in response to a received 

20 input event in accordance with one embodiment of 
the present invention. 

Figure 4 is a block diagram of a typical computer 
system suitable for implementing an embodiment of 
the present invention. 

25 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0014] Reference will now be made in detail to a pre- 

30 f erred embodiment of the invention. An example of the 
preferred embodiment is illustrated in the accompany- 
ing drawings. While the invention will be described in 
conjunction with a preferred embodiment, it will be 
understood that it is not intended to limit the invention to 

35 one preferred embodiment. To the contrary, it is 
intended to cover alternatives, modifications, and equiv- 
alents as may be included within the spirit and scope of 
the invention as defined by the appended claims. 
[0015] A method of reducing the number of light 

40 weight processes assigned by an operating system is 
illustrated in the various drawings. As described above, 
it is generally desirable for an operating system to have 
light weight processes available to be assigned to a 
generic process (e.g. a parent or child process), 

45 threads operating within or outside a process, jobs, and 
other executable entities operating in an operating sys- 
tem. Because the resources available to light weight 
processes in an operating system is limited, and the 
amount of resources is proportional to the size of the 

so system, i.e. , number of users, amount of data, etc., light 
weight processes will not have the resources they need 
to operate if there is significant growth on the system or 
if the system is not configured to make efficient use of 
its resources, regardless of the size of the computing 

55 environment. Once the pool of light weight processes 
no longer has resources it can draw from, overall per- 
formance of a computer network significantly deterio- 
rates. For example, the operating system may have to 
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perform context switching to accommodate the needs of 
processes, and users' requests, implemented by 
threads, must wait for light weight processes thereby 
slowing response time. 

[0016] For example, in the described embodiment, a s 
thread represents a client connection. Following this 
example, the client connection can be to a mail mes- 
sage store on a server in which the user wants to 
access mail messages. An active connection in this 
context represents a user session to a message store in 
a large network. In this environment, a parent process 
receives user requests to access a mail message store 
manages several child processes, each containing typi- 
cally many active connection threads. This configuration 
of the described embodiment is shown in Figure 1 . 
[0017] Figure 1 is a block diagram showing various 
components of a message access configuration and 
method in accordance with one embodiment of the 
present invention. In the described embodiment, the 
messages stored and accessed are Internet e-mail 
messages. An Internet Message (IM) access daemon 
100 resides on a network mail server, such as an IMAP 
server which may also contain a message store. A par- 
ent process 102 within daemon 100 is responsive to 
data (typically commands or requests to connect) sent 
from clients 104. Requests to connect 106 from clients 
are stored in a queue and are received by the server at 
a port depending on the protocol in which the request is 
being made. Once the server responds to a request 
106, a connection 108 with a client is established and 
the client can begin sending data, such as commands 
for accessing and manipulating mail. 
[0018] The parent process 102 has control of several 
concurrently operating child processes 1 10. It maintains 
a list of child processes 1 1 2 under its control. Each child 
process 110 has several threads of various types that 
can be in one of several states. In the described embod- 
iment, there are 50 to 200 threads in each child process. 
Once a connection is established between a client and 
a server, a session is established between a thread and 
that client, shown at line 114. 

[001 9] In the described embodiment, a child process, 
a thread, and a connection associated with that thread 
each have a number or identifier. This information is 
stored in a shared memory 116, having a series of data 
cells 118, that can be read and updated by all child 
processes. The shared memory 116 is useful because 
typically child processes are not aware of each other's 
existence and cannot communicate. In other preferred 
embodiments, a shared memory may not be needed if 
child processes are able to communicate directly. In the 
described embodiment, as soon as a child process is 
created, shared memory cells 1 1 8 associated with that 
child process are allocated by the parent process. In 
other preferred embodiments the shared memory may 
be allocated by the child process itself or by other enti- 
ties in the operating system. 

[0020] Once a thread is created within a child process, 



a thread-specific data cell 118 is assigned to that 
thread. In the described embodiment, this shared mem- 
ory 11 6 is created and pre-allocated by the parent proc- 
ess when the server is activated. In other preferred 
embodiments, the shared memory 116, if needed, can 
be created by other entities in the operating system. As 
mentioned, the shared memory is made up of a series 
of data cells. These cells 1 1 8 are identified by a coordi- 
nate "/" corresponding to a process and a coordinate 
corresponding to a thread within that process. Thus, cell 
(Pj.Tj) is a thread-specific data cell, which also contains 
a connection number "k" that allows one thread to 
inform other threads of its actions, such as updating a 
mailbox or copying messages from a mailbox. The 
thread-specific data cells 1 18 of the described embodi- 
ment in shared memory 1 1 6 allow a thread to inform all 
other threads under the same parent process of that 
thread's actions. Thus, the shared memory resides on 
the server and is pre-allocated and controlled by a par- 
ent process once the parent process is invoked. 
[0021] In prior art systems, each active connection 
thread would have to have its own light weight process 
in order to detect any incoming input events directed to 
it. In a system having a high volume of users, all actively 
accessing mail and receiving new mail messages, the 
number of light weight processes can be quickly 
depleted or reach very low levels. This would result in 
users on the network not being able to access their 
mailboxes or not allowing new users to establish con- 
nections to the message store. Both these events are 
highly undesirable given the high performance stand- 
ards users now expect from e-mail system. 
[0022] Figure 2 is an illustration of an input wait table 
associated with a process in accordance with one 
embodiment of the present invention. Beginning at the 
top layer of the method of the described embodiment, 
the operating system receives an input event. This is 
generally some type of activity generated by a user or 
some external source, such as another computer net- 
work. In the present invention, the operating system is 
suited for a distributed computing environment. By way 
of example, an operating system suitable for use in the 
present invention can be a Unix-based operating sys- 
tem such as the Solaris™ operating system of Sun 
Microsystems, Inc. or a DOS-based operating system 
such as the Windows NT™ operating system of Micro- 
soft Corp. The input event can be a normal user 
request, such as checking for new mail or sending a 
request to print a document, or it can be a less frequent 
event such as an interrupt signal. Regardless, the input 
event is normally directed generally to process and spe- 
cifically to a thread. A method in accordance with one 
embodiment of the present invention is described fully 
with regard to Figure 2. In the preferred embodiments, 
one table can hold information on more than one proc- 
ess. The table shown in Figure 2, referred to in the dis- 
cussion of Figure 2, is associated generally with a 
process within the operating system, which contains dif- 
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ferent types of threads. In addition to being a network- 
based operating system, the operating system of the 
present invention is a multi-threaded operating system. 
A process having threads representing connections to 
users (or external entities) has an associated input wait 
table for monitoring and routing input events to an 
event's corresponding thread or threads. It is possible 
that in the described embodiment a process can have 
only one thread or no threads. 
[0023] In a typical connection, a thread is generally 
waiting for input or some type of activity to occur the 
majority of the time the thread is in existence. In the 
described embodiment, the input wait table for a proc- 
ess stores information on which connections, i.e., 
threads, are in a wait state and which are executing or 
processing an input event. In the described embodi- 
ment, the operating system assigns to the process a 
light weight process for maintaining the process's input 
wait table. The operating system of the described 
embodiment schedules light weight processes which 
include assigning them to threads when a thread needs 
one {e.g. when a thread makes a call to the operating 
system or performs an I/O operation). One type of light 
weight process can be described as an execution ena- 
bler that allows a thread to execute. In other preferred 
embodiments, an operating system may use another 
type of execution enabler similar to a light weight proc- 
ess, of which there is a limited number available in the 
system and should be assigned prudently and effi- 
ciently. The thread associated with the input wait table 
invokes a special thread referred to as a polling thread 
when an input event is received. The polling thread polls 
or scans the table to determine which connection or 
connections the input event is directed to and changes 
the state of the connection from the wait state to a state 
indicating that it has received input that needs to be 
processed. It should be noted that the input wait table of 
the described embodiment may be implemented using 
other data constructs such as a queue or a linked list. In 
these embodiments, the polling thread would still have 
the same function of checking each entry in the data 
structure for determining which ones have received an 
input event. Similarly, the receipt of an input event can 
be manifested in various ways in other preferred 
embodiments using, by way of example, semaphores, 
flags, or other types of variables. The polling thread has 
a single execution enabler assigned to it, which in the 
described embodiment is a light weight process. As will 
be discussed in greater detail below, this greatly 
reduces the need for each connection to have assigned 
its own light weight process. Once the polling thread 
has scanned the table and changed the state of the 
appropriate connections, a conditional wait thread that 
monitors changes to connection entries in the table is 
responsible for having any altered connections 
assigned a light weight process or execution enabler of 
some sort thereby enabling that now active connection 
to execute. 



[0024] Referring now to Figure 2, an input wait table 
200 of the described embodiment includes a file 
descriptor column 202 for holding file descriptors 204 
representing connections, a thread identifier column, 

5 206 for holding thread identifiers 208, a conditional wait 
variable column 210 for holding wait indicators 212, and 
a error return column 214 for holding error return values 
216. In other preferred embodiments, an input wait table 
may have more columns or fewer columns as appropri- 

10 ate without altering the primary function of the table. As 
mentioned above, in other preferred embodiments, a 
process may use a data structure other than a table for 
storing data on its connections or threads and remain 
within the scope of the present invention. In the 

is described embodiment, a connection is represented by 
a row 218 in table 200. 

[0025] In the described embodiment, a file descriptor 
204 represents a connection of a particular process. 
When a new connection is associated with a process, it 

20 is represented in the process by a file descriptor since, 
in the context of a process, a connection is essentially a 
file. Thus, each connection within a process is repre- 
sented by a file descriptor. In the described embodi- 
ment, when a connection is taken from the wait state to 

25 an execution (or "GO") state, and then returns to a wait 
state, it keeps the same file descriptor but has a new 
entry in the input wait table. In other preferred embodi- 
ments, the connection can keep the same file descriptor 
as well as the same row in the input wait table, and not 

30 need to initialize a new entry in the table. 

[0026] Thread identifier 208 is a unique value that 
identifies a thread and is different from the thread's file 
descriptor. The thread identifier 208 is used in connec- 
tion with posting a thread semaphore or thread condi- 

35 tional wait variable 212. In the described embodiment, 
the thread conditional wait variable 212 is a flag that 
indicates whether the thread is in an input wait state or 
execution state. A polling thread scans the table to 
determine which thread or threads have input events 

40 directed to them and sets variable 21 2 to "GO." Another 
thread or light weight process then starts that thread. 
Thus, wait variable 212 is a thread-specific flag used to 
indicate the state of a thread. The error return value 216 
is used to store any error conditions encountered by the 

45 thread. In other preferred embodiments, the input wait 
table can have additional or fewer columns or fields 
depending on the particular platform in which the proc- 
ess is running or other system and application require- 
ments. Furthermore, in other preferred embodiments, a 

so process can use another type of data structure to store 
data regarding threads allowing a polling thread repre- 
sented by a single lightweight process, or similar execu- 
tion enabler, to manage input events and thread 
execution. 

55 [0027] An input wait table as described above with 
respect to Figure 2 is used in a method of receiving an 
input event and executing the appropriate connection 
thread while reducing consumption of light weight proc- 
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esses. Figure 3 is a flowchart showing a method of exe- 
cuting a connection thread in response to a received 
input event in accordance with one embodiment of the 
present invention. At step 302 the operating system 
detects an input event or some type of activity, for exam- 
ple a user request or a system interrupt. This input 
event is typically directed to a connection, represented 
by an active connection thread in a process. The oper- 
ating system alerts the process containing the active 
connection thread, where the active connection thread 
is represented by a file descriptor. In the described 
embodiment, the system uses the file descriptor associ- 
ated with the input event to determine which process to 
alert. As discussed with respect to the file descriptor 
column 302 of Figure 3, each thread is represented and 
identified in the operating system and in the input wait 
table by a file descriptor 204. 

[0028] At step 302 the light weight process associated 
with the process's polling thread is placed in a RUN 
state. This occurs when a process is alerted that one of 
its threads has an input event. The polling thread has a 
light weight process assigned to it but is asleep until its 
process is alerted, at which point the polling thread is 
awakened. At step 304 the polling thread begins execu- 
tion. In the described embodiment, a light weight proc- 
ess allows a connection thread to execute by allowing it 
to perform necessary functions, such as making system 
calls or performing input/output operations. 
[0029] At step 308 the polling thread scans the input 
wait table to determine which file descriptors, or 
threads, have an input event. In the described embodi- 
ment it unblocks those file descriptors that have all 
event by changing tile state of the thread's conditional 
wait variable 212. In the described embodiment this is 
done by signaling the conditional wait variable to "1 " if 
there is an input event and leaving the thread unaltered 
if there is no input event for the thread. In the described 
embodiment, a thread is placed in an input wait state by 
calling an operating system function called WaitForlnput 
which sets the conditional wait variable 212 to "0" and 
waits on the conditional wait variable. In other preferred 
embodiments, the thread or process can call other rou- 
tines or have other procedures for placing a thread in a 
wait state by, for example, setting a semaphore or flag. 
[0030] At step 310 a conditional wait thread in the 
process that oversees the connection threads to detect 
which connection threads have had state changes 
ensures that those threads are assigned light weight 
processes so they can execute. In the described 
embodiment, this "conditional wait" light weight process 
checks to see what the polling thread has done to the 
connection threads and behaves accordingly. At step 
312 of the described embodiment, the thread deletes its 
entry in the input wait table before it proceeds to proc- 
ess the input event. At step 314 each awakened thread 
processes its input event or activity, which it can now do 
since it has been assigned a light weight process. Once 
the thread has processed the input event, the thread ini- 



tializes a new entry in the input wait table to indicate its 
return to the input wait state. In the described embodi- 
ment, the conditional wait variable is set to "0" by calling 
a WaitForlnput function and waiting on the conditional 

5 wait variable. In other preferred embodiments, the 
thread can use the same entry it had previously occu- 
pied in the input wait table without initializing a new one 
when it is done processing the input event. Whether the 
table is static in which rows are reused or dynamic in 

10 which new rows are initialized does not effect the under- 
lying functionality and purpose of the input wait table. 
[0031] Once a new entry for the thread in the input 
wait table has been initialized, the light weight process 
allowing execution of the thread is released from that 

15 thread. The conditional wait thread mentioned above 
can then reassign the light weight process to another 
thread or return it to the pool of light weight processes in 
the operating system. By releasing the light weight proc- 
ess from the thread when the thread is done executing, 

20 the system realizes benefits of the polling thread. In pre- 
vious systems, the light weight process would remain 
with the thread even when the thread was idle or waiting 
for input. In the present invention, the polling thread 
using the input wait table and working in conjunction 

25 with the "conditional waif thread, greatly reduces the 
consumption of light weight processes by connection 
threads by allowing them to be assigned to threads only 
when needed. 

[0032] As described above, the present invention 

30 employs various computer-implemented operations 
involving data stored in computer systems. These oper- 
ations include, but are not limited to, those requiring 
physical manipulation of physical quantities. Usually, 
though not necessarily, these quantities take the form of 

35 electrical or magnetic signals capable of being stored, 
transferred, combined, compared, and otherwise 
manipulated. The operations described herein that form 
part of the invention are useful machine operations. The 
manipulations performed are often referred to in terms, 

40 such as, producing, identifying, running, determining, 
comparing, executing, downloading, or detecting. It is 
sometimes convenient, principally for reasons of com- 
mon usage, to refer to these electrical or magnetic sig- 
nals as bits, values, elements, variables, characters, 

45 data, or the like. It should remembered, however, that all 
of these and similar terms are to be associated with the 
appropriate physical quantities and are merely conven- 
ient labels applied to these quantities. 
[0033] The present invention also relates to a device, 

so system or apparatus for performing the aforementioned 
operations. The system may be specially constructed 
for the required purposes, or it may be a general pur- 
pose computer selectively activated or configured by a 
computer program stored in the computer. The proc- 

55 esses presented above are not inherently related to any 
particular computer or other computing apparatus. In 
particular, various general purpose computers may be 
used with programs written in accordance with the 
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teachings herein, or, alternatively, it may be more con- 
venient to construct a more specialized computer sys- 
tem to perform the required operations. 
[0034] Figure 4 is a block diagram of a general pur- 
pose computer system 400 suitable for carrying out the s 
processing in accordance with one embodiment of the 
present invention. Figure 4 illustrates one embodiment 
of a general purpose computer system. Other computer 
system architectures and configurations can be used for 
carrying out the processing of the present invention. 10 
Computer system 400, made up of various subsystems 
described below, includes at least one microprocessor 
subsystem (also referred to as a central processing unit, 
or CPU) 402. That is, CPU 402 can be implemented by 
a single-chip processor or by multiple processors. CPU is 
402 is a general purpose digital processor which con- 
trols the operation of the computer system 400. Using 
instructions retrieved from memory, the CPU 402 con- 
trols the reception and manipulation of input data, and 
the output and display of data on output devices. 20 
[0035] CPU 402 is coupled bi-directionally with a first 
primary storage 404, typically a random access mem- 
ory (RAM), and uni-directionally with a second primary 
storage area 406, typically a read-only memory (ROM), 
via a memory bus 408. As is well known in the art, pri- 25 
mary storage 404 can be used as a general storage 
area and as scratch-pad memory, and can also be used 
to store input data and processed data. It can also store 
programming instructions and data, in the form of 
threads and processes, for example, in addition to other 30 
data and instructions for processes operating on CPU 
402, and is used typically used for fast transfer of data 
and instructions in a bi-directional manner over the 
memory bus 408. Also as well known in the art, primary 
storage 406 typically includes basic operating instruc- 35 
tions, program code, data and objects used by the CPU 
402 to perform its functions. Primary storage devices 
404 and 406 may include any suitable computer-reada- 
ble storage media, described below, depending on 
whether, for example, data access needs to be bi-direc- 40 
tional or uni-directional. CPU 402 can also directly and 
very rapidly retrieve and store frequently needed data in 
a cache memory 430. 

[0036] A removable mass storage device 41 2 provides 
additional data storage capacity for the computer sys- 45 
tern 400, and is coupled either bi-directionally or uni- 
directionally to CPU 402 via a peripheral bus 414. For 
example, a specific removable mass storage device 
commonly known as a CD-ROM typically passes data 
uni-directionally to the CPU 402, whereas a floppy disk so 
can pass data bi-directionally to the CPU 402. Storage 
412 may also include computer-readable media such as 
magnetic tape, flash memory, signals embodied on a 
carrier wave, PC-CARDS, portable mass storage 
devices, holographic storage devices, and other storage 55 
devices. A fixed mass storage 416 also provides addi- 
tional data storage capacity and is coupled bi-direction- 
ally to CPU 402 via peripheral bus 414. The most 



common example of mass storage 416 is a hard disk 
drive. Generally, access to these media is slower than 
access to primary storages 404 and 406. Mass storage 
412 and 416 generally store additional programming 
instructions, data, and the like that typically are not in 
active use by the CPU 402. It will be appreciated that 
the information retained within mass storage 412 and 
416 may be incorporated, if needed, in standard fashion 
as part of primary storage 404 (e.g. RAM) as virtual 
memory. 

[0037] In addition to providing CPU 402 access to 
storage subsystems, the peripheral bus 414 is used to 
provide access other subsystems and devices as well. 
In the described embodiment, these include a display 
monitor 418 and adapter 420, a printer device 422, a 
network interface 424, an auxiliary input/output device 
interface 426, a sound card 428 and speakers 430, and 
other subsystems as needed. 

[0038] The network interface 424 allows CPU 402 to 
be coupled to another computer, computer network, or 
telecommunications network using a network connec- 
tion as shown. Through the network interface 424, it is 
contemplated that the CPU 402 might receive informa- 
tion, e.g., data objects or program instructions, from 
another network, or might output information to another 
network in the course of performing the above- 
described method steps. Information, often represented 
as a sequence of instructions to be executed on a CPU, 
may be received from and outputted to another network, 
for example, in the form of a computer data signal 
embodied in a carrier wave. An interface card or similar 
device and appropriate software implemented by CPU 
402 can be used to connect the computer system 400 to 
an external network and transfer data according to 
standard protocols. That is, method embodiments of the 
present invention may execute solely upon CPU 402, or 
may be performed across a network such as the Inter- 
net, intranet networks, or local area networks, in con- 
junction with a remote CPU that shares a portion of the 
processing. Additional mass storage devices (not 
shown) may also be connected to CPU 402 through net- 
work interface 424. 

[0039] Auxiliary I/O device interface 426 represents 
general and customized interfaces that allow the CPU 
402 to send and, more typically, receive data from other 
devices such as microphones, touch-sensitive displays, 
transducer card readers, tape readers, voice or hand- 
writing recognizers, biometrics readers, cameras, porta- 
ble mass storage devices, and other computers. 
[0040] Also coupled to the CPU 402 is a keyboard 
controller 432 via a local bus 434 for receiving input 
from a keyboard 436 or a pointer device 438, and send- 
ing decoded symbols from the keyboard 436 or pointer 
device 438 to the CPU 402. The pointer device may be 
a mouse, stylus, track ball, or tablet, and is useful for 
interacting with a graphical user interface. 
[0041] In addition, embodiments of the present inven- 
tion further relate to computer storage products with a 
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computer readable medium that contain program code 
for performing various computer-implemented opera- 
tions. The computer-readable medium is any data stor- 
age device that can store data which can thereafter be 
read by a computer system. Tile media and program 5 
code may be those specially designed and constructed 
for the purposes of the present invention, or they may 
be of the kind well known to those of ordinary skill in the 
computer software arts. Examples of computer-reada- 
ble media include, but are not limited to, all the media w 
mentioned above: magnetic media such as hard disks, 
floppy disks, and magnetic tape; optical media such as 
CD-ROM disks; magneto-optical media such as floptical 
disks; and specially configured hardware devices such 
as application-specific integrated circuits (ASICs), pro- 15 
grammable logic devices (PLDs), and ROM and RAM 
devices. The computer-readable medium can also be 
distributed as a data signal embodied in a carrier wave 
over a network of coupled computer systems so that the 
computer-readable code is stored and executed in a 20 
distributed fashion. Examples of program code include 
both machine code, as produced, for example, by a 
compiler, or files containing higher level code that may 
be executed using an interpreter. 

[0042] It will be appreciated by those skilled in the art 25 
that the above described hardware and software ele- 
ments are of standard design and construction. Other 
computer systems suitable for use with the invention 
may include additional or fewer subsystems. In addition, 
memory bus 408, peripheral bus 414, and local bus 434 30 
are illustrative of any interconnection scheme serving to 
link the subsystems. For example, a local bus could be 
used to connect the CPU to fixed mass storage 416 and 
display adapter 420. The computer system shown in 
Figure 4 is but an example of a computer system suita- 35 
ble for use with the invention. Other computer architec- 
tures having different configurations of subsystems may 
also be utilized. 

[0043] Although the foregoing invention has been 
described in some detail for purposes of clarity of 40 
understanding, it will be apparent that certain changes 
and modifications may be practiced within the scope of 
the appended claims. For instance, the input wait table 
can contain information on threads in more than one 
table by having an additional process identifier column. 45 
In another example, the input wait table can have more 
or fewer columns as needed by the system. Further- 
more, it should be noted that there are alternative ways 
of implementing both the process and apparatus of the 
present invention. Accordingly, the present embodi- so 
ments are to be considered as illustrative and not 
restrictive, and the invention is not to be limited to the 
details given herein, but may be modified within the 
scope and equivalents of the appended claims. 

55 

Claims 

1. A method of handling an input event to a multi- 



threaded process that includes a plurality of active 
connection threads, the method comprising: 

alerting the multi-threaded process that the 
input event effecting a selected one of the 
active connection threads has been received; 
enabling a polling thread contained in the multi- 
threaded process; 

determining the active connection thread con- 
tained in the multi-threaded process to which 
an input event is directed using the polling 
thread and associated thread-specific data; 
and 

triggering the selected active connection 
thread to handle the input event. 

2. A method as recited in claim 1 wherein enabling a 
polling thread further includes assigning an execu- 
tion enabler to the polling thread and running the 
execution enabler. 

3. A method as recited in claim 2 wherein the execu- 
tion enabler is a light weight process. 

4. A method as recited in any one of the preceding 
claims wherein determining the active connection 
the thread further includes: 

checking a list of threads maintained by the 
process wherein each thread can be identified 
by a file descriptor and wherein the list of 
threads includes for each thread the file 
descriptor, a thread identifier, a thread wait var- 
iable, and an error return code. 

5. A method as recited in any one of the preceding 
claims further including changing the state of the 
thread wait variable when there is an input event 
directed to a thread associated with the thread wait 
variable. 

6. A method as recited in any one of the preceding 
claims further including enabling a conditional wait 
thread for monitoring changes to active connection 
threads in the list. 

7. A method of invoking a thread in a process when 
the process receives an event directed to the 
thread, the method comprising: 

alerting the process, the process having a plu- 
rality of threads and associated thread -specif ic 
data, that an input event effecting one such 
thread contained in the process has been 
received; 

enabling a polling thread contained in the proc- 
ess; 

determining which thread contained in the 
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process to which an event is directed using the 
polling thread and the associated thread-spe- 
cific data; and 

triggering each of the threads in the plurality of 
threads which has an event to process that s 
event. 

8. A method of handling an input event to a multi- 
threaded process that includes a plurality of active 
connection threads, the method comprising: 10 

receiving an input event directed at a selected 
one of the active connection threads; 
using a polling thread associated with the plu- 
rality of the active connection threads to deter- 15 
mine which of the plurality of active connection 
threads the input event is directed to; and 
triggering the selected active connection 
thread to handle the input event, thereby 
assigning a light weight process to the selected 20 
active connection thread to facilitate execution 
of the selected active connection thread, 
whereby each active connection thread does 
not require a dedicated light weight process to 
facilitate the detection of the input event that is 25 
directed to the selected active connection 
thread, thereby reducing consumption of light 
weight processes within the multi-threaded 
process. 

30 

9. A method as recited in claim 8 further including run- 
ning a conditional wait thread to monitor changes 
made to the plurality of active connection threads 
having an input event to ensure execution of the 
selected active connection thread. 35 

10. A computer system having a multi-threaded proc- 
ess capable of receiving an input event from a user 
directed to a specific thread contained in the proc- 
ess, the system comprising: 40 

an input polling thread arranged to detect an 
input event directed to a selected active con- 
nection thread in the multi -threaded process 
and to route the input event to the selected 45 
thread whereby only the input polling thread 
requires a light weight process to detect an 
input event thereby reducing consumption of 
light weight processes by the active connection 
threads used for detecting input events; and so 
an input wait table associated with the process 
and structured for monitoring and storing infor- 
mation on active connection threads, such 
information indicating which active connection 
threads are executing an input event; 55 
whereby the input polling thread polls the input 
wait table to determine which active connection 
thread the input event is directed to thereby 
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reducing the need for the active connection 
threads in the process to individually monitor 
input events thereby lowering the number of 
light weight processes running in the computer 
system. 

11. A computer system as recited in claim 10 further 
comprising a conditional wait thread for monitoring 
the input wait table to determine which selected 
active connection thread has had a state change 
thereby ensuring that the selected active connec- 
tion thread is assigned a light weight process. 

12. A computer system having a multi-threaded proc- 
ess capable of receiving an input event from a user 
directed to a specific thread contained in tile proc- 
ess, the system comprising: 

a means for detecting an input event directed to 
a selected active connection thread in the 
multi-threaded process and to route the input 
event to the selected thread whereby only the 
input polling thread requires a light weight proc- 
ess to detect an input event thereby reducing 
consumption of light weight processes by the 
active connection threads used for detecting 
input events; and 

a means for monitoring and storing information 
on active connection threads, such information 
indicating which active connection threads are 
executing an input event; 
whereby the input polling thread polls the input 
wait table to determine which active connection 
thread the input event is directed to thereby 
reducing the need for the active connection 
threads in the process to individually monitor 
input events thereby lowering the number of 
light weight processes running in the computer 
system. 

13. A computer system as recited in claim 12 further 
comprising a means for monitoring the input wait 
table to determine which selected active connection 
thread has had a state change thereby ensuring 
that the selected active connection thread is 
assigned a light weight process. 

14. A computer-readable medium containing program- 
ming instructions for handling an input event to a 
multi-threaded process that includes a plurality of 
active connection threads, the computer-readable 
medium comprising computer program code 
devices configured to cause a computer to execute 
the steps of: 

alerting the process that an input event effect- 
ing a selected one of the active connection 
threads has been received; 
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enabling a polling thread contained in the proc- 
ess; 

determining which of the active connection 
threads contained in the process has an event 
directed to it using the polling thread and asso- 
ciated thread-specific data; and 
triggering the selected active connection 
thread to handle the input event. 

15. A computer-readable medium as recited in claim 14 
further including computer program code devices 
configured for changing the state of the thread wait 
variable when there is an input event directed to a 
thread associated with the thread wait variable. 

16. A computer-readable medium as recited in claim 14 
or 15 further including computer program code 
devices configured for enabling a conditional wait 
thread for monitoring changes to active connection 
threads in the list. 

17. A computer-readable medium as recited in claim 
14, 15, or 16 wherein the computer program code 
devices configured to cause a computer to enable a 
polling thread further includes computer program 
code devices configured to cause a computer to 
execute the step of enabling a polling thread further 
includes assigning an execution enabler to the poll- 
ing thread and running the execution enabler. 

18. A computer-readable medium as recited in claim 
14, 15, 16, or 17 wherein the computer program 
code devices configured to cause a computer to 
determine which of the active connection threads 
contained in the process has an event directed to it 
further includes computer program code devices 
configured to cause a computer to execute the step 
of checking a list of threads maintained by the proc- 
ess wherein each thread can be identified by a file 
descriptor and wherein the list of threads includes 
for each thread the file descriptor, a thread identi- 
fier, a thread wait variable, and an error return code. 

19. A computer system configured to receive input 
events from a plurality of users directed to a specific 
active connection thread contained in a multi- 
threaded process, the system comprising: 

a means for alerting the multi-threaded process 
that an input event effecting a selected one of 
the active connection threads has been 
received; 

a means for enabling a polling thread contained 
in the process; 

a means for determining which of the active 
connection threads contained in the process 
has an input event directed to it using the poll- 
ing thread and associated thread-specific data; 



and 

a means for triggering the selected active con- 
nection thread to handle the input event. 

5 20. A computer-readable medium containing program- 
ming instructions for invoking a thread in a process 
when the process receives an event directed to the 
thread, the computer-readable medium comprising 
computer program code devices configured to 

10 cause a computer to execute the steps of: 

alerting the process, the process having a plu- 
rality of threads and associated thread -specif ic 
data, that an input event effecting a thread con- 
15 tained in the process has been received; 

enabling a polling thread contained in the proc- 
ess; 

determining which of the threads contained in 
the process has an event directed to it using 
20 the polling thread and the associated thread- 

specific data; and 

triggering each of the threads in the plurality of 
threads which has an event to process that 
event. 

25 

21. A computer-readable medium containing program- 
ming instructions for handling an input event to a 
multi-threaded process that includes a plurality of 
active connection threads, the computer-readable 

30 medium comprising computer program code 
devices configured to cause a computer to execute 
the steps of: 

receiving an input event directed at a selected 

35 one of the active connection threads; 

using a polling thread associated with the plu- 
rality of the active connections threads to deter- 
mine which one of the plurality of active 
connection threads the input event is directed 

40 to; and 

triggering the selected active connection 
thread to handle the input event, thereby 
assigning a light weight process to the selected 
active connection thread to facilitate execution 

45 of the selected active connection thread, 

whereby each active connection thread does 
not require a dedicated light weight process to 
facilitate the detection of the input event that is 
directed to the selected one of the active con- 

50 nection threads, thereby reducing consumption 

of light weight processes within the multi- 
threaded process. 

22. A computer-readable medium as recited in claim 21 
55 further including computer program code devices 

configured for running a conditional wait thread to 
monitor changes made to the plurality of active con- 
nection threads having an input event to ensure 
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execution of the selected active connection thread. 

23. A computer system configured to receive input 
events from a plurality of users directed to a specific 
active connection thread contained in a process, s 
the system comprising: 

a means for receiving art input event directed 
at a selected one of the active connection 
threads; 10 
a means for using a polling thread associated 
with the plurality of the active connections 
threads to determine which one of the plurality 
of active connection threads the input event is 
directed to; and 15 
a means for triggering the selected active con- 
nection thread to handle the input event, 
thereby assigning a light weight process to the 
selected active connection thread to facilitate 
execution of the selected active connection 20 
thread, 

whereby each active connection thread does 
not require a dedicated light weight process to 
facilitate the detection of the input event that is 
directed to the selected one of the active con- 25 
nection threads, thereby reducing consumption 
of light weight processes within the multi- 
threaded process. 

24. A computer system as recited in claim 23 further 30 
comprising a means for running a conditional wait 
thread to monitor changes made to the plurality of 
active connection threads having an input event to 
ensure execution of the selected active connection 
thread. 35 

25. A computer system configured to receive input 
events from a plurality of users directed to a specific 
active connection thread contained in a process, 

the system comprising: 40 

a means for alerting the process, the process 
having a plurality of threads and associated 
thread-specific data, that an input event effect- 
ing a thread contained in the process has been 45 
received; 

a means for enabling a polling thread contained 
in the process; 

a means for determining which of the threads 
contained in the process has an event directed so 
to it using the polling thread and the associated 
thread-specific data; and 
a means for triggering each of the threads in 
the plurality of threads which has an event to 
process that event. 55 
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RECEIVED 




FIG. 3 



O/S RECEIVES INPUT EVENT 
AND ALERTS PROCESS ASSOC. 
WITH INPUT EVENT'S FILE 
DESCRIPTORS 
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LIGHT WEIGHT PROCESS 
ASSIGNED TO POLLING THREAD 
IS RUN 
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POLLING THREAD BEGINS 
EXECUTION 



306 



POLLING THREAD SCANS INPUT 
WAIT TABLE & UNBLOCKS EACH 
THREAD WHICH HAS IN 
INPUT EVENT 
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CONDITIONAL WAIT LIGHT 
WEIGHT PROCESS EXECUTES 

EACH THREAD WITH 
CONDITIONAL WAIT VAR = "0" 
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EACH AWAKENED THREAD 
DELETES ITS CORRESPONDING 
ENTRY IN INPUT WAIT TABLE 
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EACH AWAKENED THREAD 
PROCESSES ITS INPUT 
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THREAD CREATES A NEW 
ENTRY IN INPUT WAIT TABLE 
& THREAD'S CONDITIONAL 
WAIT VAR SET TO "1" 
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